iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 10
4

Event Storming Part 4 - 可以做的更好

Event Storming 可以幫助我們解決溝通與學習的問題,但一場需要激烈討論的會議要舉辦起來也並不是那麼地簡單。如果沒有達到幾點關鍵要素,那你將花掉的是跨團隊間的時間,成本不小。

本篇我將從反向案例來看,一場失敗的 Event Storming 會出現哪一些問題,接著再聊聊一些可以做得更好的細節。也歡迎大家給我回饋。

失敗的 Event Storming 長怎樣

Event Storming 非常地耗費心神,所以很容易在不知不覺的情況下走偏。當遇到以下情況時,不管你身兼何種角色(主要是主持人),都必須公開提出來讓會議導回正軌。

[X] 追求完美、每個問題都想要解決

Event Storming 最原始的目標就是將領域專家腦中的想法具現化出來,讓在場的開發人員更好地吸收,甚至回饋。這邊不需要嚴格到程式設計的精準性,也不可能立即把所有的 Hotspot 都給解決。

所以這時候如果與會者的背景多元一些,就能多一些決策依據。比如領域專家可能只做商業決策,但對於客戶的理解不如業務,又或者對於串接外部系統的複雜度不如開發者。

當你發現這個問題已經討論了快半小時還未果,那可能這個問題不適合在這場會議解決。標記他,記錄討論的內容,待幾天後再回來。

Event Storming 不是開發產品的 Brain Storming。

[X] 個人秀或是審查委員會

當 Event Storming 變成個人秀時,就失去了原有跨領域學習的優勢。另外由於與會者彼此間的個性差異、又或者公司內的階級制度使然,甚至單純是總是有部分人更了解整個商業流程,有時候尤其是沒有太多經驗或自信的與會者可能會不敢自己做決定,反而事事都要問那些比較有聲音的人,或更糟地有一個委員會小團體決定這是否可以貼上去,這在無形間就違反了 Event Storming 的本意。

Event Storming 最大的優點之一就是打破團隊間的穀倉效應,讓知識不在各自掌握在手中,而是共同匯聚起來完成產品。

當你對於你手上便利貼的敘述不夠自信時,請不要怕,先貼再說。同時主持人也可以多多鼓勵大家先動手再討論。待到整合階段時,再一一檢視每一張便利貼。很多時候,不同的意見與想法反而可以找出系統潛在的問題或機會。

同時也很常發生一個場景,就是在探索階段有兩人一直互相問答,這樣一來,問答一旦拉長,很容易吸引其他人的目光,導致漸漸變成大家聽兩人的對話。記住,Event Storming 並不是一場圍繞著領域專家、以他為依據的活動。我反而認為,每一個人的平均發聲量才是評量一場 Event Storming 成功的標準。

在避免鎂光燈聚集在那些懂很多的人身上時,有時候也會發生一些懂很多的人不願意交流,認為之前他們都開會好幾遍,資訊都寫在文件裡面了啊,在這邊重講一遍很浪費時間。但事實上, Event Storming 本意是為了開發者的知識理解。畢竟對開發者而言,看 Spec 非常無聊且吸收效率很糟。

[X] 突然進入太多技術細節

身為一名開發者,看到商業流程就會自動轉換為程式碼也是再正常不過了。甚至有時候看到「幾乎不能相容」於現有系統的商業流程時就會開始慌了手腳,想將會議暫停。

首先,我認為開發者如果能夠提出如「開發成本過高」等建議的確是實用的,但還是要先首重於先理解領域專家腦袋中的構想圖。我相信當開發者能夠看到更全面的商業模式後,自然可以在下一階段提出每個流程哪隱含的成本供領導層決策。

另外,當開發者開始進入細節要畫出 UML、快取、資料庫等等術語時,就相當程度地忽略了一旁的非技術人員。當人們發現自己無法加入話題時,自然參與的熱情就會下降,讓團隊交流的意義消失。

[X] 太累了拉,只要人到,就算有些桌子椅子也無妨

這點有可能是在 Event Storming 導入初期容易被受到質疑的地方。考量到不同人的體力狀況,要大家久站這麼長時間是一個不小的挑戰。我的經驗是,如果今天是開實體會議,那請還是務必遵守。

因為當你中間擺了張桌子,一來不便於走動,二來大家之間的距離又被凸顯出來。而椅子方面,對於一個要一直走動貼便利貼的活動來說,坐著這件事就是最大的殺手,一旦有位子坐我幹嘛站著?那這樣能夠「風暴」出的豐富性就會大打折扣。

我的建議是,可以適時地安排休息時間,讓大家能夠適度休息。但時間到了,務必要在有效率的時間內完成會議。

血淚經驗談

以下我會介紹一些我個人實作上踩過的雷與建議:

多一張圖示你就少十分鍾解釋

我非常建議大家不論是手繪還是列印,將各種便利貼的用法做成海報(或國軍小卡)張貼出來,讓大家可以第一眼就看到。

一來,可以減少你講解的時間,二來也可以減少事後跟別人解釋的時間。很多時候,即使是第一次參加的人,你都會訝異於他們學習如此的快速,很多時候你只需要點出某便利貼的關鍵特性,大家就可以很快地舉一反三,甚至找出你沒有想過的可能性。

前面提到,問問題在前期的探索階段會影響到 Event Storming 展開的效率,此時有一張圖示在那邊不但增加效率,同時也避免大家誤會便利貼的用法。

為你的色彩上圖:為便利貼加上 ICON

在 Event Storming 這場色彩遊戲之中,可能有些人因為色彩辨識比較不敏感,而難以加入會議。因此,在便利貼的一角加上一個可以區分類型的小圖標,可以讓大家更自在的溝通。當然,這也可以畫在你的圖示海報上,讓大家看到。

在你的商業流程中加上軸心 (Pivot)

當你前幾個階段將大致的 Event 都標記上去後,你可以考慮用一個有色膠帶將畫面中特別重要或是關鍵的 Event 貼上標記起來,讓畫面分為數個空間,這樣有助於討論時一次聚焦在一個區段。

主持人的職責

要當一名稱職的主持人並不容易,要隨時注意現場的狀況。尤其是一開始,大家還很沈默怕犯錯的,這時候主持人可以試著多問問題來引導大家。甚至,你不需要當一個「聰明」的人,問一些明顯的問題、貼一些可能有點問題的 Event 都是破冰的好方法。當然,如果你是老手,你也可以透過類似的手法引導大家。再次重申,Event Storming 不在於追求完美,而在於碰中出火花。

我們在乎的是溝通的過程,而非把成果放到美術展覽。

尤其注意那些聲量過大或聲量過小的與會者,盡量去搭起兩者間的橋樑,讓會議更平衡一點。很多問法諸如「如果這邊出錯會怎麼樣?」、「這件事總是會還是偶爾發生嗎?」、「這個 Event 發生前有什麼必要條件嗎?」,甚至用倒敘法將事件回朔也可以。

再來,雖然可以讓大家多多發揮,但主持人必須堅持 Event 在「過去式」的使用法則。因為這種用法並不是十分地直覺,有時即便是老手也可能犯錯,這時主持人要幫大家做品質把關。

最後,時間控管是主持人最重要的工作,所以這邊我不太建議主持人身兼領域專家。通常領域專家常會陷入討論的戰火之中,甚至還有些意猶未盡。這時候主持人要注意會議的時間,將一些明顯進入死結的問題先懸置起來,讓大家可以繼續往下討論。但有時候想要插入一個話題需要藝術等級的手法,因此使用個計時器,應用類似番茄鐘的計時法則可以幫助你在時間到的時候,自然地停止話題。

領域專家職責

雖然說 Event Storming 沒有主角,但領域專家的確是整場會議的關鍵元素之一。主持人在事先籌劃時必須與領域專家達成共識,那就是領域專家是來解惑的不是製造疑惑的。領域專家在會議前也必須針對主題做調查,或是寫出幾份實際案例讓自己了解可能的使用情境。

領域專家必須要有自我意識,而非現場挑個人當。

在這裏,領域專家也可以考慮走 BDD 常用的 Spec By Example 的 Given When Then 語法,將業務規則的前因後果都寫出來,有助於自己理解。

Summary

Event Storming 的精神在於「溝通」與「學習」,為的就是讓開發人員可以更好地理解商業需求,同時也順便讓領域專家找出自己的盲點。

總結本篇,我認為有以下關鍵要素來衡量一場成功的 Event Storming:

  • 群體學習 > 課堂講課
  • 全部人的參與 > 少數人的派對
  • 多元的聲音 > 單一的看法

Resources


上一篇
Event Storming Part 3 - 軟體設計
下一篇
軟體架構淺談
系列文
Think in Domain-Driven Design30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言